-
Notifications
You must be signed in to change notification settings - Fork 369
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rename API group "networking" to "controlplane" #1147
Conversation
Thanks for your PR. The following commands are available:
|
/test-all |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this close #1122? The issue was about revisiting all API groups, not just networking
?
Do you know if this affects upgrade? IIRC, renaming the API group used in an APIService may create issues, if we stop serving the original API in the Antrea Controller apiserver. As much as possible we should try to concentrate API changes that may affect upgrade within the same release.
So far we just concluded on this change only. But if you like to keep the issue open, I am fine too.
There can be period that controller and agent are not at the same version, and then agent cannot watch the computed networkpolicy objects from controller (so networkpolicy changes will not take effect). I feel this is acceptable, but like to hear your thoughts and suggestions. |
Yes I forgot this one! Does it require API group versions not changed too? If not we can keep an empty networking group. But I guess version must be the same too. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Found some unexpected changes, guess the PR is not done yet.
The problem is applying the new yaml won't delete the stale "v1beta1.networking.antrea.tanzu.vmware.com" APIService, but antrea-controller is no longer serving it so we would meet the same issue as #494 as the upgrade test failure shows:
@antoninbas and I discussed how to deal with it before, we got two options:
Along with the evolution of APIs, like v1alpha1 -> v1beta1 -> v1, we may need to handle this case anyway. |
I guess let us go this approach. What you think a separate initContainer which can be activated when we need to handle API service in upgrade, and can be removed when not needed? For example, we execute an antctl command or run controller in special mode to do the cleanup. |
I like the idea of doing it in the Antrea Controller even if it does require additional permissions.
It seems that wildcards are not supported in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mid way i saw you plan to address goland mistakes..
+1 seems okay to grant this to Antrea controller with specific resource names |
Thanks @abhiraut for the review. Let me do a thorough check of all changes. |
732e426
to
81c4e8c
Compare
After looking at the code, I also agree let controller delete the APIService is much simpler, as controller now already updates APIServices. Made the change. Please check. @antoninbas @abhiraut @tnqn |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Deletion logic LGTM, a few comments
pkg/apiserver/apiserver.go
Outdated
// otherwise K8s will reject to delete an existing Namespace created | ||
// before the upgrade. Also check the information at: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion: s/will reject to delete/will fail to delete
also question: is it just for Namespaces that existed before the upgrade? I thought that was for all Namespaces (because every time a Namespace is deleted, K8s reaches out to all APIServices to see if they have any object that needs to be deleted). See kubernetes/kubernetes#60807 (comment). I may be wrong though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed to "will fail to delete".
You are right. It should be all Namespaces before the APIService is deleted. Updated the comments.
@@ -130,6 +130,12 @@ func run(o *Options) error { | |||
if err != nil { | |||
return fmt.Errorf("error creating API server: %v", err) | |||
} | |||
|
|||
err = apiserver.CleanupDeprecatedAPIServices(aggregatorClient) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't think of it too much but does the order matter here? should we remove deprecated APIServices before installing the new ones?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Installation happens locally on controller, and new APIServices are already registered when applying the YAML. Before apiserver starts, K8s knows nothing about the new API groups. So, I think it does not matter.
resources: | ||
- apiservices | ||
resourceNames: | ||
# Add the APIServices for the deprecated APIGroups here. antrea-controller |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for adding the comment!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we have a timeline in terms of releases for how long we plan to attempt deleting old apiservices? ie after X releases we will no longer clean up..
91c35fc
to
4a819c0
Compare
/test-all |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
/test-all |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm.. one minor nit.. but lets merge so we can resolve conflicts on other PRs
resources: | ||
- apiservices | ||
resourceNames: | ||
# Add the APIServices for the deprecated APIGroups here. antrea-controller |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we have a timeline in terms of releases for how long we plan to attempt deleting old apiservices? ie after X releases we will no longer clean up..
@abhiraut I think we should keep including all deprecated APIServices until we make a v1.0 release |
thanks for the answer! |
5367fd0
Codecov Report
@@ Coverage Diff @@
## master #1147 +/- ##
==========================================
- Coverage 43.79% 43.48% -0.31%
==========================================
Files 140 140
Lines 15146 15246 +100
==========================================
- Hits 6633 6630 -3
- Misses 7928 8027 +99
- Partials 585 589 +4
Flags with carried forward coverage won't be shown. Click here to find out more.
|
/test-all |
* Rename API group "networking" to "controlplane" * Delete the registered APIService for "networking" API group
* Rename API group "networking" to "controlplane" * Delete the registered APIService for "networking" API group
* Rename API group "networking" to "controlplane" * Delete the registered APIService for "networking" API group
* Rename API group "networking" to "controlplane" * Delete the registered APIService for "networking" API group
Closes #1122